start needs to be at least a configurable number of hours in the future (default 24)#5815
Conversation
|
for #5784 |
roborivers
left a comment
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Success ✓.
Regression testing: Success ✓.
The first 10 failing tests are:
sc_resume_logicalsc_generated
sc_swapfields
consumer_non_atomic_default_consumer_generated
remsql_locks_rte_connect_generated
remsql_locks
sc_downgrade
reco-ddlk-sql
|
@dorinhogea Thank you! |
|
How about making it a day in advance (since the smallest granularity is daily). Otherwise if the schema change takes longer than a hour, the current shard will have date which would've belonged to the next rollout. Changing it to a day makes it a lot less likely to happen. |
|
There is no good value here; we had collapses that take days. Less then 24 hours let use actually test the collapse feature (since daily is the fastest possible rollout). The retroactive partitioning is not meant to be surgical; too new rows will go in the shard 0, too old rows go to shard 1. |
dorinhogea
force-pushed
the
block2oldretro
branch
from
885f7d5 to
a6419bc
Compare
|
when id doubt, make it configurable (defaults to 24 hours) |
dorinhogea
changed the title
…re (default 24) Signed-off-by: Dorin Hogea <dhogea@bloomberg.net>
dorinhogea
force-pushed
the
block2oldretro
branch
from
a6419bc to
018cb15
Compare
roborivers
left a comment
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Success ✓.
Regression testing: Success ✓.
The first 10 failing tests are:
sp_snapshot_generated
consumer_non_atomic_default_consumer_generated
sc_transactional_rowlocks_generated
remsql_locks_rte_connect_generated
remsql_locks
reco-ddlk-sql
|
@riverszhang89 thank you |
3 participants
This is simply to prevent the case when clients choose a start time for retroactive time partition in the past. Start is the next rollout, not the first rollout.